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This  work  was  performed  totally  in-house,  under  Job  Order  No.  55810006, 
by  the  Management  Information  Sciences  Section  of  the  Information  Processing 
Branch,  Information  Sciences  Division. 

This  report  represents  the  results  of  a survey  of  design  techniques  and 
guidelines  which  could  be  employed  in  the  development  of  a secure  data  base 
management  system.  The  techniques  are  presented  as  solutions  to  particular 
design  problems;  not  in  terms  of  a general  theoretical  framework.  However, 
where  there  is  evidence  that  certain  techniques  indicate  such  a general  frame- 
work, the  evidence  is  presented  and  the  principle  discussed. 

The  author  takes  this  opportunity  to  express  his  appreciation  to 
Mr.  Marvin  Schaefer  of  System  Development  Corp.  for  his  helpful  comments  and 
suggestions  in  this  work. 
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SECTION  1 


INTRODUCTION 

Since1  February  1972,  the  Directorate  of  Information  Systems  Technology 
of  the  Electronics  Systems  Division  (ESD)  has  been  engaged  in  a program  to 
develop  a prototype,  secure  multilevel  access  computer  system.  This  program 
addresses  security  issues  involved  in  the  design  of  the  central  computet , the 
front-end  communications  processor,  and  remote  terminals.  From  October  1972 
to  September  1975,  the  Information  Sciences  Division  of  Rome  Air  Development 
Center  (RADC)  sponsored  a program  of  research  into  the  implications  of 
application  engineering  in  a secure  computer  environment.  The  objective  of 
this  program  was  the  prototype  design  of  an  open,  secure,  multilevel  data 
base  management  system  (DBMS).  This  report  discusses  some  of  the  technical 
considerations  involved  in  designing  a secure  DBMS  and  examines  the  functional 
and  cost  impact  of  military  security  requirements  on  such  a design. 


SECTION  2 


BACKGROUND 

A precise  specification  of  military  computer  security  requirements  (19) 
formed  the  technical  basis  for  both  the  ESD  and  RADC  programs.  This  specifica- 
tion is  embodied  in  a mathematical  model  (12).  The  model  consists  of: 

(1)  Security  Objects  - the  entities  to  which  access  is  controlled 
and  includes  data  files,  directories,  terminals  and  tape  drives.  The  data 
files  will  be  of  primary  concern  in  the  design  of  a secure  DBMS. 

(2)  Subjects  - the  entities  which  represent  users.  Subjects  are 
themselves  objects  with  respect  to  the  granting  and  rescinding  of  user  access 
permission . 

(3)  Rules  - directives,  consistent  with  military  security  policy, 
which  determine  whether  a request  by  a program  to  access  data  may  be  allowed. 
They  also  regulate  the  granting  and  rescinding  of  user  permission. 

(4)  Access  Matrix  - a data  structure  to  store  all  of  the  informa- 
tion necessary  to  determine  the  access  rights  of  subjects  with  respect  to 
security  objects. 

This  model  is  referred  to  as  a "reference  monitor"  (2). 

It  must  be  proven  that  a computer  system  using  the  reference  monitor 
implements  exactly  the  rules  and  definitions  of  the  mathematical  model.  This 
is  the  certification  procedure.  In  order  to  facilitate  certification, 

Schell  (18)  has  proposed  that  the  security  related  functions  of  a computer 
system  be  centralized  into  a "security  kernel"  (1).  This  kernel  must  provide 
complete  mediation;  i.e.,  the  security  controls  must  be  invoked  at  every 
attempted  access  to  the  objects  of  the  system.  It  must  also  be  isolated  from 
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the  non-security  related  remainder  of  the  system  so  that  the  programs  and 
data  which  implement  the  security  controls  are  tamper-proof.  Finally,  it 
must  be  simple  so  that  the  controls  are  readily  understood  and,  as  a result, 
amenable  to  certification. 

The  mediation  and  isolation  pr  ciples  present  requirements  on  the  kind 
of  computer  system  hardware  architecture  necessary  to  ensure  the  performance 
viability  of  a kernel-monitored  computer  system.  Mediation  demands  hardware 
assisted  access  checking,  and  isolation  requires  multiple  machine  states  to 
separate  the  kernel  from  the  remainder  of  the  operating  system  (OS)  and  from 
users . 

Contemporary  hardware  technology  is  available  to  satisfy  both  of  these 
requirements  in  terms  of  the  "descriptor  driven  machine".  This  architecture 
is  distinguished  by  hardware  segmentation.  Segmentation  makes  possible  the 
logical  partitioning  of  all  storage  resources  into  machine  addressable,  two- 
dimensional  segments.  This  architecture  facilitates  a virtual  memory 
consisting  of  segments  as  opposed  to  conventional  files.  Segmentation 
satisfies  the  security  kernel  mediation  and  isolation  requirements  because 
each  reference  to  the  two-dimensional  virtual  memory  must  be  translated  into 
the  one-dimensional  physical  memory  by  the  segmentation  hardware.  It  is  at 
the  time  of  this  translation  that  access  and  machine  state  verification  is 
performed  with  only  minute  overhead  costs.  Examples  of  descriptor  driven 
machines  are  the  Digital  Equipment  Corporation  PDP-11/45  (7)  and  the 
Honeywell-6180  (11).  The  latter  machine  supports  eight  operating  states  so 
that  security  kernel,  OS,  user  and  applications,  such  as  a Secure  DBMS,  can 
coexist  within  the  machine,  each  in  an  environment  protected  from  the  others 
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SECTION  3 


DBMS  SECURITY  REQUIREMENTS 

Six  security  related  requirements  must  be  satisfied  by  a Secure  DBMS 
design: 

(1)  Security  - the  DBMS  must  support  the  military  system  of  non- 
discretionary (information  classifications  and  categories,  personnel 
clearances)  and  discretionary  (need-to-know)  security  controls  which  ensure 
that  only  properly  cleared  and  authorized  computer  users  are  allowed  access 
to  classified  data. 

(2)  *-property  - this  rule,  first  stated  in  the  mathematical  model, 
recognizes  the  potential  computer  security  compromise  inherent  in  the 
capability  of  a cleared  user  to  "write  down"  sensitive  information  into  the 
data  files  of  an  uncleared  user.  It  prevents  the  "write  down"  operation  by 
only  allowing  a user  to  write  information  into  objects  whose  classification 

is  equal  to  or  greater  than  his  clearance. 

(3)  Denial  of  Service  - it  must  be  impossible  to  disable  the  DBMS 
so  as  to  make  the  data  base  inaccessible  or  unusable. 

(4)  Unnecessary  Disclosure  - the  DBMS  must  prevent  users  from 
knowing  of  the  existence  of  portions  of  the  data  base  to  which  they  are  not 
allowed  access. 

(5)  Over-classification  of  Data  - the  DBMS  must  organize  data 
structures  so  as  to  minimize  the  over-classification  of  data  and  the  attendant 
costs  and  problems  of  over-cleared  personnel. 

The  first  five  requirements  are  derived  from  the  nominal  military  security 
requirements.  The  following  three  requirements  are  indirectly  related  to 
security  and  attempt  to  characterize  the  functional  nature  of  the  intended  DBMS 


design . 
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(6)  Utilization  of  OS  Security  Controls  - the  DBMS  must  maximize 
its  utilization  of  existing  OS  security  controls  so  as  to  minimize  the  already 
increased  cost  of  access  checking  and  to  avoid  the  complications  of  certifying 
the  correctness  of  its  own  security  control  algorithms. 

(7)  Data  Base  Attributes  - the  data  base  will  consist  of  many  large 
files.  However,  less  than  one  percent  of  the  data  will  be  classified  (2). 
Although  a number  of  the  files  will  be  used  by  only  one  application  function, 
the  vast  majority  of  files  must  satisfy  the  needs  of  several  applications 
simultaneously. 

(8)  User  Interface  - the  DBMS  will  be  primarily  oriented  toward 
on-line,  interactive  usage,  but  will  also  have  to  satisfy  the  demand  for  an 
application  program  interface. 

The  following  sections  describe  some  considerations  in  the  design  of  a 
Secure  DBMS  and  examine  the  functional  and  cost  impact  of  the  eight  security 
requirements . 
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SECTION  4 


DATA  ORGANIZATION 

Since  security  controls  impose  an  additional  burden  on  system  performance, 
the  objective  of  data  organization  in  a Secure  DBMS  design  is  to  choose  a DBMS 
security  object  which  will  maximize  the  use  of  OS  security  mechanisms,  i.e., 
the  security  kernel.  Potential  candidates  are  the  file,  the  record,  the  item 
and  the  f ield  (9)  . 

The  data  file  is  the  obvious  first  choice  as  the  DBMS  security  object. 

It  is  most  readily  mapped  into  the  OS  security  data  object  - the  segment.  The 
natural  advantage  of  this  organization  is,  of  course,  cost-free  DBMS  security 
controls,  since  the  kernel  provides  access  control  over  the  segment.  In 
addition,  this  choice  also  encompasses  the  record  as  a security  object.  The 
record  is  an  important  design  consideration  because  of  the  almost  universal 
acceptance  of  this  organization  with  its  natural  accessing  efficiencies. 

Because  less  than  one  percent  of  the  data  base  is  expected  to  be  classified, 
it  is  reasonable  to  assume  that  only  a few  of  the  data  fields  of  a record  will 
be  classified.  However,  since  an  occurrence  of  such  a field  appears  in  every 
record  of  a file,  all  of  the  records  must  be  classified  to  accommodate  the 
most  restricted  data  they  contain.  The  aggregate  of  records  naturally 
comprises  a file,  and  a file's  homogeneous  classification  naturally 
accommodates  its  component  records.  The  obvious  disadvantage  of  the  file 
and  record  security  objects  is  the  over-classification  of  the  record's 
remaining  (unclassified)  data  fields. 

As  a reaction  to  the  over-classification  problem,  the  data  item  as  the 
DBMS  security  object  is  a natural  choice.  However,  to  maintain  a cost-free 


DBMS  security  mechanism,  it  becomes  necessary  to  store  one  data  item  per 
segment  - an  intolerably  expensive  situation  in  terms  of  OS  accessing  and 
maintenance  costs.  This  forces  a data  item  organization  in  which  several 
(optimally  many)  data  items  are  collocated  in  one  segment.  If  these  items 
are  not  homogeneously  classified,  the  data  item  becomes  a security  object 
distinct  from  those  supported  by  the  OS.  In  this  situation  the  DBMS  must 
support  the  data  item  object  with  its  own  security  kernel  and  in  a manner 
identical  to  the  OS  kernel.  Lacking  hardware  assistance,  this  mechanism  must 
be  implemented  entirely  in  software.  Even  if  it  is  assumed  that  the  problem 
of  certifying  the  correctness  of  this  presumably  large  program  can  be  over- 
come, its  cost  in  terms  of  system  performance  would  be  totally  unacceptable. 

As  a consequence,  heterogeneously  classified  data  items  stored  in  a segment 
must  be  clearly  rejected  as  DBMS  security  objects. 

The  alternate  choice,  that  of  storing  homogeneously  classified  data  items 
in  a segment,  appears  attractive  for  several  reasons.  A set  of  uniformly 
classified  data  items  finds  a natural  representation  in  a DBMS  data  field, 
since  this  is  the  usual  manner  in  which  data  is  classified.  Since  the  field 
is  stored  in  the  homogeneously  classified  segment,  access  control  is  obtained 
at  no  additional  cost.  The  problem  of  over-classification  of  data  is  elimi- 
nated. Finally,  this  data  organization  naturally  accommodates  set  theoretic 
operations  on  the  data  fields,  referred  to  as  data  sets,  and  has  been  explored 
by  Schaefer  and  Hink<  (17).  Owens  (15)  has  described  the  privacy  implications 
of  this  organization  in  a non-military  environment. 

The  primary  disadvantage  of  the  data  field  organization  is  its 
inefficiency  in  accessing  "data  records".  Partitioning  an  n-field  record 
into  n distinct  data  sets  can  imply  n distinct  disk  accesses  to  "fetch"  a 
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record.  Experience  with  the  similar,  completely  inverted  data  organization 
of  the  Time-Shared  Data  Management  System  (TDMS)  (3)  indicates  that  this 
approach  becomes  practicable  for  military  applications  only  when  it  has  been 
adapted  to  a more  conventional  data  organization,  such  as  in  the  SACCS/DMS  (13). 
However,  not  all  data  base  queries  and  updates  require  all  of  the  component 
fields  of  a record.  If  the  fields  are  organized  as  binary  search  trees  (14), 
typical  data  base  element  operations  (search,  sequential  processing,  insertion/ 
deletion)  are  not  unreasonably  costly. 

As  a result  of  these  considerations,  two  data  organizations  appear 
feasible: 

(1)  Uniformly  classified  data  records. 

(2)  Uniformly  classified  data  items,  i.e.,  the  data  field  or 

data  set. 

Each  of  these  aggregates  must  be  stored  in  a segment  whose  classification 
equals  that  of  the  data. 
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INDEXING 


An  index  on  a record-oriented  data  file  is  a collection  of  data  item, 
data  pointer  pairs,  where  the  items  comprise  a data  field  and  the  pointers 
refer  to  the  records  containing  the  respective  data  items.  Indices  have 
long  been  used  to  improve  the  efficiency  of  record  accessing. 

The  indexing  technique  has  several  important  security  ramifications. 
Because  it  is  founded  on  the  data  field,  an  index  has  no  additional  security 
costs  when  organized  as  a homogeneously  classified  segment.  If  the  classifi- 
cation of  the  index  and  the  file  to  which  it  points  are  the  same,  there  are 
no  unusual  security  considerations.  The  case  in  which  the  classification  of 
the  index  is  greater  than  the  classification  of  the  data  to  which  it  points 
can  occur  in  fully  inverted  data  organizations.  However,  its  usefulness  is 
limited  because  users  cleared  to  the  level  of  the  data  cannot  modify  that 
data  because  they  cannot  perform  the  required  index  modifications.  Users 
cleared  to  manipulate  the  index  must  dynamically  lower  their  clearance  level 
to  equal  that  of  the  data  file  before  attempting  to  examine  or  modify  the 
data.  This  is  equivalent  to  logging  out  and  then  logging  back  into  the 
system  during  a DBMS  operation  and  necessarily  results  in  the  "new"  process 
being  unaware  of  its  previous  actions.  The  final  case,  that  in  which  the 
classification  of  the  index  is  lower  (e.g.,  unclassified)  than  the  file  to 
which  it  refers,  is  interesting  for  two  reasons.  In  all  probability  this 
case  is  the  most  likely  situation  which  will  be  encountered.  This  conclusion 
is  based  on  the  expected  less  than  one  percent  frequency  of  classified 
information  in  typical  data  bases.  Obviously,  users  whose  clearance  equals 
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that  of  the  index  can  utilize  it,  but  not  to  access  the  data  file.  But,  more 
important,  its  value  to  users  whose  clearance  is  equal  to  or  greater  than  the 
data  file  is  quite  limited.  It  can  be  utilized  for  nominal  searching  purposes. 
However,  an  add  or  delete  record  operation  on  the  file  to  which  the  index 
refers,  implies  a *-property  violation  because  the  index  must  be  updated; 
i.e.,  the  user,  having  modified  the  data  record,  must  now  "write  down"  into 
the  lower  classified  index  to  complete  the  modification.  Again,  dynamically 
lowering  the  users  clearance  level  presents  the  kind  of  problem  described  in 
the  case  above. 

Security  requirements  have  a significant  impact  on  the  data  organizations 
of  a Secure  DBMS.  Each  of  the  data  organizations  considered  feasible  has 
significant  disadvantages.  Data  over-classification  increases  the  cost  of 
the  record,  a cost  which,  despite  the  fact  that  less  than  one  percent  of  the 
data  is  classified,  is  not  lightly  dismissed.  Functionally,  its  associated 
indices  are  severely  limited.  Although  the  data  field  has  certain  accessing 
inefficiencies,  it  appears  to  be  a functionally  sound  basis  for  a DBMS. 
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SECTION  6 


DATA  STRUCTURE 

This  section  will  consider  the  security  implications  in  data  structure 
design  for  the  record  and  field  data  organizations.  From  the  discussions  on 
data  organization  it  became  evident  that  security  requirements  dictated  an 
optimal  organization  in  which  the  classification  of  logical  DBMS  aggregates 
(e.g.,  fields,  records)  is  considered  homogeneous,  and  that  these  logical 
aggregates  are  stored  in  OS  secu- ity  objects  (e.g.,  segments)  whose  classifica- 
tion is  also  considered  homogeneous.  As  long  as  this  is  the  case,  data 
structures  may  be  constructed  using  traditional  techniques  without  concern 
for  security  compromise.  Random,  sequential  and  simple  list  structures 
composed  of  records  naturally  satisfy  these  requirements. 

When  the  security  objects  or  DBMS  aggregates  which  comprise  a data 
structure  are  of  mixed  classifications,  security  requirements  must  be 
carefully  considered.  This  configuration  is  most  frequently  encountered  in 
the  construction  of  complex  list  structures  such  as  trees  and  hierarchies. 

These  structures  provide  important  accessing  advantages  and  powerful 
organizational  techniques  and  are  crucial  in  the  implementation  of  the 
important  repeating  group  concept.  Walter,  et  al  (20)  have  studied  this 
problem  in  terms  of  the  tree-type,  hierarchical  data  structure  and  have 
concluded  that  the  classification  of  tree  nodes  must  be  monotonical ly 
increasing  from  the  root  of  the  tree.  This  restriction  prevents  security 
and  *-property  violations  However,  it  does  expose  the  structure  to  a 
denial  of  service  threat,  since  a user  can  delete  portions  of  the  tree 
substructure  to  which  he  normally  would  be  denied  access.  Schaefer  and 
Hinke  (17)  have  suggested  that  the  OS  security  kernel  recognize  the  concept 
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of  "ownership"  of  elements  in  the  hierarchy,  i.e.,  directories  and  files. 

The  owner  of  an  element  is  its  creator,  and  would,  of  course,  be  cleared  to 
access  the  element  and  would  be  the  only  subject  allowed  to  delete  it. 

Now  consider  the  implications  of  this  general  guidance  on  the  implemen- 
tation of  data  structures  for  the  record  and  field  organizations.  Figure  1 
shows  a list  of  records,  1,2, . . . ,k,k+l, . . . ,m,  where  Cl  and  C2  denote  security 
classifications,  and  it  is  assumed  that  C2  > Cl.  An  immediate  observation  of 
this  configuration  is  that  it  conforms  to  the  monotonically  increasing 
classification  restriction.  As  a result,  DBMS  functions  which  examine  or 
change  the  data,  i.e.,  read/write  record,  but  do  not  affect  the  data  structure, 
can  be  performed  on  the  records  by  users  of  both  clearance  levels  in 
accordance  with  security  requirements  and  with  no  special  problems.  However, 
the  monotonically  increasing  classification  of  this  structure  guarantees 
security  problems  when  DBMS  functions  which  change  the  data  structure,  such 
as  add  and  delete  records,  are  attempted.  For  example,  if  a user  whose 
clearance  is  C2  attempts  to  delete  either  record  k or  k+1 , he  must  modify  a 
pointer  located  in  a record  of  lower  classification.  This  is  a ^-property 
violation.  A user  whose  clearance  is  Cl  can  add  a record  of  classification 
Cl  immediately  succeeding  record  k,  but  a user  ol  clearance  C2  cannot  add  a 
record  of  any  classification  in  that  particular  location.  Again,  the  reason 
is  a potential  *-property  violation. 

These  problems  can  be  partially  resolved  if  the  user  making  the  modifica- 
tions is  provided  with  the  capability  of  dynamically  changing  his  clearance 
level.  In  the  first  example  cited  above,  the  user  would  temporarily  change 
his  clearance  level  so  that  it  equaled  Cl.  This  allows  him  to  perform  single 
level  operations  on  the  data  structure  at  a lower  level  of  clearance,  e.g., 
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Figure  1.  List  of  Records 

deleting  record  k.  However,  this  capability  does  not  permit  genuinely  multi- 
level operations,  such  as  deleting  record  k+1  or  adding  a record  of  classifies 
tion  C2  immediately  succeeding  record  k.  These  restrictions  are  significant 
because  they  are  frequently  encountered  in  operations  on  multilevel,  repeating 
group  type  structures. 
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Until  now  the  considerations  on  the  data  field  organization  have  only 
alluded  to  a special  discipline  for  manipulating  information  structured  in 
this  form.  This  discipline,  referred  to  as  a "relational  data  system"  (5,  10), 
is  based  on  the  construction  of  mathematical  relations  on  sets  of  data.  The 
data  field  organization  discussed  previously  is,  in  fact,  an  organization  by 
data  set.  Figure  2 shows  a relationai  data  system  in  which  D1  and  D2  are 
data  sets,  i.e.,  data  field  organizations  stored  in  segments.  Cl  and  C2  are 
security  classifications,  and  it  is  assumed  that  C2  > Cl.  R is  a relation  on 
the  data  sets.  Components  of  R link  individual  field  values  to  form  an  entry 
of  the  data  base.  Such  an  entry  might  describe  an  employees  name  and  his  job 
title.  The  implementation  shown  in  this  example  suggests  that  the  relation  is 
created  by  storing  pointers  to  related  data  values.  Alternatively,  Codd  (6) 
has  suggested  a normalized  data  organization  which  eliminates  the  need  for 
inter-segment  pointers  and  allows  associative  storing  of  Rs  components. 
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The  relational  approach  to  data  base  management  has  many  desirable 
features.  Representations  of  data  organizations,  such  as  the  record,  and 
data  structures  composed  of  records,  such  as  lists  and  trees,  can  be 
implemented  using  relations.  The  relations  can  then  be  manipulated  using 
powerful  set  theoretic  operations.  However,  as  previously  noted  in  the  data 
organization  considerations,  there  are  some  questions  about  the  large  file 
performance  capabilities  of  this  approach. 

The  basic  set  theoretic  operations  (union,  intersection,  difference, 
projection,  join,  product,  composition)  (15)  which  can  be  performed  on  the 
data  sets  have  a common  property  - they  all  create  new  relations,  i.e.,  data 
sets.  For  example,  intersection  creates  a new  relation  with  component 
elements  which  are  common  to  several  data  sets.  Product  creates  a new 
relation  which  aggregates  data  sets  together  in  a manner  that  could  be  used 
to  affect  records.  As  a result,  examination  and  modification  of  the  relations 
involve  operations  on  only  the  segment  which  contains  the  relation.  Clearly, 
only  the  user  authorized  to  access  this  segment  can  perform  the  operations. 

For  example,  deleting  an  entry  which  consists  of  heterogeneously  classified 
data  set  components  involves  the  removal  of  the  pointer  information  which 
affects  that  entry.  Deleting  the  entire  relation  implies  deleting  a segment 
from  the  system.  In  either  case,  the  individual  data  values  in  the  component 
data  sets  are  unaltered.  These  values  are  physically  removed  by  operations  on 
the  individual  data  sets  themselves,  i.e.,  operations  on  homogeneously 
classified  data.  Likewise,  the  changing  of  data  values  must  be  performed  via 
a relation  which  the  user  is  authorized  to  access.  Adding  an  element  to  an 
existing  multilevel  relation  requires  writing  in  segments  of  different 
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classifications  - a ^-property  violation.  This  special  case  of  multilevel 
data  entry  will  be  considered  in  a later  section. 

Complex  data  structures,  such  as  repeating  groups,  can  be  implemented 
using  relations.  Figure  3 shows  the  relation  R linking  three  child  data 
elements  to  their  parent.  Modifications  to  such  heterogeneously  classified 
structures  are  straightforward  operations  on  the  homogeneously  classified 
relation  segments,  except  in  the  case  of  adding  repeating  group  elements. 
This  is  another  instance  of  the  general  problem  of  guaranteeing  *-property 
preservation  while  performing  the  multilevel  data  entry  function. 


Dl  R D2 


Figure  3.  Repeating  Group  Structure  in  a 
Relational  Data  System 

It  would  appear  that  a straightforward  application  of  Weissmans  "high- 
water  mark”  strategy  (21)  would  satisfy  the  security  requirements  of 
relational  data  systems.  For  example,  the  classification  of  a relation 
created  by  the  union  operation  would  be  the  same  as  the  classification  of 
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the  most  restricted  data  set  used  to  effect  the  union.  Its  category  would  be 
the  more  restrictive  union  of  the  category  sets  of  its  components.  Its  need- 
to-know  list  must  be  formed  as  the  intersection  of  the  need-to-know  lists  of 
its  components.  However,  as  discussed  by  Owens  (15),  the  powerful,  set 
theoretic  operations  can  be  used  in  subtle  ways  to  derive  and  infer  informa- 
tion about  the  data  base.  The  general  problem  of  satisfying  the  security 
requirements  of  functions  which  allow  data  aggregation  and  inference  is  just 
beginning  to  be  explored. 

From  the  preceding  considerations  it  is  clear  that  the  major  impact  of 
the  security  requirements  on  data  structure  design  is  functional  rather  than 
economic.  The  most  serious  problems  affect  complex  data  structures,  such  as 
trees.  In  particular,  a tree  structure  of  heterogeneously  classified  records, 
organized  so  that  the  classifications  of  the  tree  nodes  are  monotonically 
increasing,  induces  ^-property  violations  when  modifications  to  the  structure 
are  attempted.  Relational  data  systems  escape  these  difficulties  because  of 
their  basic  data  organization.  However,  this  kind  of  system  contains  subtle 
and  difficult  data  aggregation  and  inference  problems. 
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SECTION  7 
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COORDINATED  DATA  SHARING 

Coordinated  data  sharing  refers  to  the  synchronized  reading  and  writing 
of  the  same  unit  of  data  by  several  concurrent  user  processes  operating  in  a 
multiprogramming  environment.  Its  objective  is  to  increase  system  accessing 
efficiency  while  preserving  data  integrity. 

Coordinated  data  sharing  is  implemented  by  allowing  users  to  gain 
mutually  exclusive  use  of  data.  This  is  done  by  establishing  "critical 
regions"  (4)  in  the  programs  which  manipulate  the  data.  The  mutually 
exclusive  use  of  data  is  guaranteed  during  execution  of  a critical  region. 

The  implementation  of  critical  regions  is  based  on  Dijkstra's  P and  V 
operations  on  semaphores  (8) . Note  that  it  is  crucial  that  all  users  who 
access  the  data  base  do  so  by  using  the  programs  which  implement  critical 
regions.  If  independent,  spurious  accesses  are  possible,  the  critical  region 
programs  cannot  guarantee  mutual  exclusion,  and  as  a result,  data  integrity 
is  lost.  This  situation  can  be  avoided  by  placing  both  the  data  base  and  the 
programs  which  access  it  in  a machine  state  which  is  protected  from  the 
general  user  community.  Users  wishing  to  access  the  data  base  are  now  forced 
to  do  so  using  only  programs  provided  by  the  DBMS,  i.e.,  programs  which 
implement  critical  regions.  Note  that  the  use  of  a special  machine  state  to 
"protect"  the  data  from  uncontrolled  access  is  a data  integrity  issue.  It  is 
not  security  related.  It  is  part  of  a technique  for  controlling  the  actions 
of  those  users  who  already  have  legitimate  access  to  the  data  base. 

The  security  implications  of  a controlled  data  sharing  environment 
center  iround  the  manner  in  which  users  make  known  their  data  sharing  require- 
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merits  to  competing  users.  This  is  normally  done  by  means  of  algorithms  which 
provide  users  with  mutually  exclusive  access  to  a shared  data  base  of  data 


requests.  If  the  users  and  the  data  are  of  the  same  classification,  the 
security  requirements  are  satisfied.  However,  a user  who  is  cleared  to  and 
works  at  a clearance  level,  C2,  is  unable  to  express  his  data  sharing  require- 
ments to  a user  operating  at  a clearance  level,  Cl,  where  C2  > Cl,  because  this 
kind  of  "write-down”  operation  is  a ^-property  violation. 

Schaefer  (16)  has  suggested  "reader  and  writer"  algorithms  which  avoid 
^-property  violations  when  executed  by  users  who  are  operating  at  different 
clearance  levels.  These  algorithms  use  the  P and  V operations  on  a single 
semaphore  to  implement  critical  regions.  They  allow  a user  whose  clearance 
is  C2  to  "communicate"  with  another  user  whose  clearance  is  Cl  where  C2  > Cl, 
by  observing  a semaphore  whose  classification  is  Cl.  In  essence,  these 
algorithms  (see  Figure  4)  allow  the  user  (writer)  operating  at  the  classifica- 
tion level  of  the  data  to  gain  exclusive  access  by  means  of  the  semaphore. 


WRITER 


READER 


P(s); 

k :=  k +1; 

write; 

V(s); 


loop:  pause(quantum) ; 

t :=  k; 

IF  s = 0 GOTO  loop; 
read ; 

IF  t = k GOTO  loop; 


where 


"s"  is  a semaphore  variable, 

"k"  and  "t"  are  integer  variables, 

"pause" is  a system  primitive  which  will  permit  a unit  of 
time  equal  to  "quantum”  to  go  by  prior  to  reactivating  the 
code  sequence  from  which  it  is  called. 

Figure  4.  Multilevel  Coordinated  Data 
Sharing  Algorithms 
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In  addition,  this  user  must  signal  the  start  of  his  write  operation,  via  "k". 
The  user  (reader)  operating  at  a level  higher  than  the  classification  of  the 
data  is  allowed  to  observe  the  semaphore  and  read  the  data.  Because  "k"  is 
maintained,  the  reader  is  able  to  detect  the  possibility  that  the  data  has 
been  modified  while  his  read  was  in  progress.  In  this  case  he  simply  tries 
to  read  the  data  again.  These  algorithms  guarantee  the  preservation  of  the 
security  rules  and  the  integrity  of  the  data. 

As  noted  by  Schaefer  (16),  these  versions  of  the  "reader  and  writer" 
algorithms  have  two  disadvantages.  They  do  not  allow  for  positive  determina- 
tion of  the  reading  of  inconsistent  data,  but  only  of  its  possibility.  As  a 
result,  their  use  may  imply  the  unnecessary  rereading  of  data.  This  is 
expensive  in  terms  of  system  response  time.  These  algorithms  also  contain  an 
inherent  denial  of  service  threat.  It  is  possible  for  a user  operating  at 
clearance  level  Cl  to  permanently  block  a user  operating  at  clearance  level 
C2  from  accessing  data  whose  classification  is  Cl.  If  this  data  is  contin- 
uously being  changed  by  a user  operating  at  the  lower  clearance  level,  then 
the  forward  progress  of  a user  trying  to  access  the  data  from  the  higher 
clearance  level  can  be  effectively  stymied.  In  addition,  the  cost  of  using 
these  algorithms  for  coordinated  data  sharing  within  a single  security  level 
is  significant. 

The  main  impact  of  the  security  requirements  on  coordinated  data  sharing 
is  economic.  It  is  clear  that  usage  of  the  algorithms  which  support  the 
coordinated  sharing  of  multilevel  data. will  incur  system  performance  costs, 
especially  for  those  users  cleared  to  and  only  accessing  information  at  a 
single  (e.g.,  the  highest)  security  level  in  the  system.  Denial  of  service  is 
also  a threat. 
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SECTION  8 


MULTILEVEL  DATA  ENTRY 

Entering  multilevel  information  into  a data  base  presents  two  significant 
problems.  The  first  occurs  in  the  transfer  of  data  from  the  input  media 
(e.g.,  magnetic  tape,  punched  cards)  into  the  primary  memory.  The  second 
occurs  during  the  logical  interconnection  of  heterogeneously  classified  data 
elements  to  create  complex  data  structures. 

Transferring  multilevel  data  from  the  input  media  to  primary  memory 
involves  a potential  *-property  violation.  Since  the  input  media  will  be 
classified  at  the  level  of  the  most  sensitive  data  which  it  contains,  the 
user  reading  this  media  into  the  system  must  be  cleared  to  and  operate  at 
that  level.  Because  of  the  ^-property,  this  user  can  only  write  the  data  into 
segments  whose  classification  is  also  that  of  the  most  sensitive  data  contained 
on  the  media.  The  user  can  move  the  multilevel  data  into  the  system  but  cannot 
partition  it  into  segments  on  the  basis  of  classification  level. 

This  problem  may  be  resolved  by  providing  a certified  secure  program  to 
perform  this  function.  Execution  of  such  a program  results  in  a "trusted 
process",  which  could  be  located  either  as  part  of  the  security  kernel  or  in 
the  system's  front-end  communication  processor.  Certification  of  this  program 
can  be  justified  by  its  general  applicability  to  system  users,  in  addition  to 
users  of  the  DBMS.  It  appears  that  the  trusted  process  approach  is  costly 
both  in  terms  of  its  certification  and  its  interpretive  method  of  operation. 

Schaefer  and  Hinke  (17)  identify  the  second  multilevel  data  entry  problem 
as  occurring  in  the  creation  of  complex  data  structures.  This  is  a generali- 
zation of  the  special  case  of  adding  an  element  to  a data  structure  and  was 
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alluded  to  in  the  considerations  on  data  structure.  Basically,  the  problem 
is  the  potential  for  *-property  violations  when  a data  structure  is  being 
created  by  interconnecting  heterogeneously  classified  data  elements.  In  the 
case  of  a tree-type  structure  with  repeating  groups,  it  is  necessary  to  write 
in  parent  nodes  the  locations  (addresses,  pointers)  of  their  repeating  group 
children.  Because  of  the  monotonically  increasing  security  classification  of 
a tree  structure,  some  of  the  parents  will  be  at  a higher  level  of  classifica- 
tion than  their  children.  Creating  the  interrelationships  between  such  nodes 
requires  reading  and  writing  in  data  segments  of  both  classifications.  This 
is  a *-property  violation. 

As  in  the  case  of  reading  the  input  media  into  the  system,  this  problem 
may  be  eliminated  by  providing  a trusted  process.  Unlike  the  input  media 
problem,  the  trusted  process  approach  cannot  be  as  easily  justified.  It 
would  have  special  application,  not  only  for  a DBMS,  but  for  a particular 
data  structure.  In  addition,  its  specialized  knowledge  of  the  format  of 
incoming  data  makes  the  possibility  of  its  certification  at  least  questionable. 
Schaefer  and  Hinke  (17)  have  noted  that  Codd's  data  organization  (6),  which 
normalizes  data  relationships  (e.g.,  repeating  groups)  into  a matrix-type 
structure  whose  implementation  does  not  require  inter-segment  pointers, 
provides  a more  promising  approach  to  the  solution  of  the  multilevel  data  entry 
problem. 

The  problems  associated  with  the  creation  of  complex  data  structures  are 
also  inherent  in  its  wholesale  dismantling.  This  process  often  referred  to 
as  "garbage  collection",  reorganizes  data  structure  in  order  to  improve  its 
accessing  efficiency  and  to  conserve  storage.  It  is  the  complete  analogue 
of  the  data  structure  creation  phase  of  data  entry,  and  the  consideration  of 
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those  problems  and  solutions  is  equally  applicable  to  garbage  collection. 

The  problems  involved  in  entering  data  into  a multilevel  data  base  are 
significant  both  in  terms  of  the  cost  and  functional  effectiveness  of  their 
solutions.  Even  the  most  promising  approach  - a trusted  process  - only 
eliminates  the  functional  restrictions.  Its  development  and  certification 
entail  significant  costs. 


SECTION  9 


CONCLUSIONS 

As  a result  of  these  considerations  it  appears  that  relational  data 
systems  significantly  reduce  the  impact  of  the  security  requirements  on  the 
functional  capabilities  of  a DBMS.  The  coordinated  data  sharing  algorithms 
necessitated  by  these  same  requirements  are  more  costly.  The  requirements 
also  introduce  new,  and  as  yet  unresolved,  problems  into  the  multilevel  data 
entry  function. 

It  has  always  been  understood  that  satisfying  military  security  require- 
ments would  entail  additional  operational  costs.  What  had  not  been  anticipated 
is  the  magnitude  of  the  cost,  despite  the  fact  that  only  a very  small  per- 
centage  of  the  data  may  actually  be  classified. 
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METRIC  SYSTEM 


BASE  UNITS: 

Quantity 


length 

mass 

time 

electric  current 
thermodynamic  temperature 
amount  of  substance 
luminous  intensity 

SUPPLEMENTARY  UNITS: 

plane  angle 
solid  angle 

DERIVED  UNITS: 
Acceleration 

activity  (of  a radioactive  source) 

angular  acceleration 

angular  velocity 

area 

density 

electric  capacitance 
electrical  conductance 
electric  field  strength 
eiectric  inductance 
electric  potential  difference 
electric  resistance 
electromotive  force 
energy 
entropy 
force 

frequency 
illuminance 
luminance 
luminous  flux 
magnetic  field  strength 
magnetic  flux 
magnetic  flux  density 
magnetomotive  force 
power 
pressure 

quantity  of  electricity 
quantity  of  heat 
radiant  intensity 
specific  heat 
stress 

thermal  conductivity 
velocity 

viscosity,  dynamic 

viscosity,  kinematic 

voltage 

volume 

wavenumber 

work 


SI  PREFIXES: 


Unit 


metre 

kilogram 

second 

ampere 

kelvin 

mole 

candela 


radian 

steradian 


metre  per  second  squared 

disintegration  per  second 

radian  per  second  squared 

radian  per  second 

square  metre 

kilogram  per  cubic  metre 

farad 

siemens 

volt  per  metre 

henry 

volt 

ohm 

volt 

joule 

joule  per  kelvin 

newton 

hertz 

lux 

candela  per  square  metre 
lumen 

ampere  per  metre 

weber 

tesla 

ampere 

watt 

pascal 

coulomb 

joule 

watt  per  steradian 

joule  per  kilogram-kelvin 

pascal 

watt  per  metre-kelvin 

metre  per  second 

pascal-second 

square  metre  per  second 

volt 

cubic  metre 
reciprocal  metre 
joule 


Multiplication  Factors 


1 000  000 
t 000 
1 


0 

0 000 
0.000  000 
0 000  000  000 

0.000  000  000  000 


000  000 

= 

1011 

000  000 

= 

10* 

000  000 

= 

10* 

1 000 

= 

10' 

too 

= 

10J 

to 

= 

10' 

0 1 

= 

10-' 

0 01 

= 

10*J 

0 001 

= 

10*’ 

ooo  ooi 

= 

10- * 

000  001 

a 

10- • 

ooo  ooi 

■* 

lO" 

Ooo  ooi 

= 

10'” 

tarn  001 

10-'* 

* To  be  avoided  where  possible 


SI  Symbol  Formula 


m 

kg 


A 

K 


mol 

cd 

rad 

sr 

m/s 

(disintegration  )/s 
rad/s 

rad/s 

m 

kg/m 

F 

A-s/V 

s 

A/V 

V/m 

H 

V-s/A 

V 

W/A 

VIA 

V 

W/A 

1 

N-m 

|/K 

N 

kg-m/s 

Hz 

(cycle  )/s 

lx 

lm/m 

cd/m 

Im 

cd-sr 

Aim 

Wb 

V-s 

T 

Wb/m 

A 

W 

)/» 

Pa 

C 

I 

N/m 

A-s 

N-m 

W/sr 

)/kg-K 

Pa 

N/m 

W/m-K 

m/s 

Pa-s 

m/s 

V 

W/A 

m 

i 

(wave)/m 

N-m 

Prefix  SI  Symbol 


tors 

g'g» 

megs 

kilo 

hecto 

deka* 

dec!* 

cent  I* 

mllll 

micro 

nano 

ulco 

fern  to 

alto 


T 

M 

k 

h 

da 

d 

c 

m 

M 

n 

f 


I 


MISSION 

of 

Rome  Air  Development  Center 


RADC  plans  and  conducts  research,  exploratory  and  advanced 
development  programs  in  command,  control,  and  conmunications 
(C3)  activities , and  in  the  C3  areas  of  information  sciences 
and  intelligence.  The  principal  technical  mission  areas 
are  communications , electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  objects,  intelligence 
data  collection  and  handling,  information  system  technology , 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility . 
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